A system may have one or more physical components. Further, the system may allow for components to be added and/or removed. Components may be added or removed at runtime and/or while the system is powered down. Adding or removing a component in the system may change the functionality available to and/or provided by the system. Further, adding or removing a component in the system may have an impact on other components in the system. For example, adding a component may require that the component share resources (e.g., computing cycles, physical space, memory, network bandwidth, etc.) with other resources in the system. The system may be responsible for managing the different components in the system, and may further be responsible for allocating system resources between the different components.
In addition, a component in the system may fail. For example, the component may experience a hardware failure (e.g., overheating, breakage, uncoupling from the system, or some other type of failure relating to physical hardware), a software malfunction (e.g., an infinite loop, a memory leak or fault, division by zero, or some other type of failure relating to code execution), or some other type of malfunction. The failure may render the component inoperable or otherwise unreliable. For example, the component may experience unusually high latency and/or become unresponsive. When a component fails, some sort of system recovery may be needed, such as restarting, reinitializing, and/or replacing the component.
In some systems, a polling approach is used to determine when components are added and/or removed. Specifically, a controller may transmit a message to a particular network address in the system, corresponding to the potential location of a component, and wait for a response indicating that a component is located at that address. Polling may be repeated, periodically, for each electronic address in the system. Polling allows the system to determine whether components are located at different addresses, but carries significant overhead, because the system must poll each and every location periodically. Thus, polling may consume valuable system resources such as computing cycles, bandwidth, memory, etc.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.